-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Scenarios to improve legibility and workflow management. #315
Conversation
Changes how scenarios works per description in #277 and updates relevant documentation about API changes. Also: - various efficiencies and consistency fixes
So you aren't iterating over a changing list
@i-am-sijia or @lmz would love your attention on this next as it will enables some good stuff going on in |
…into change_project_apply_handling
@lmz see updated documentation to review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Ran the scenario creation notebook and tests\test_scenario.py, both are currently failing due to bugs in scenario.py
- Link and Node foreign keys has upper case variables, but the project card reading step is converting everything in project cards into lower case. This is causing most of the tests to fail.
Co-authored-by: Sijia Wang <[email protected]>
Also: - Better document Scenario.__init__ arguments - Require minimum variables in base_scenario: applied_projects and conflicts
…p-sag/network_wrangler into change_project_apply_handling
- is_disjoint is actually isdisjoint (doh!) and performed on a set object - mapping objects converted to lists (doh!) - `planned_proejects` should actually be `_planned _projects` - _queued_projects should be truthiness-checked, not ever none
also: - fixed a lot of API usage - added specific Exception types for better error catching in testing - black
I was trying to take a look at this by running
The error says "... is valid under ..." |
Yeah - this sux and has to do with the project card not the scenario handling...which is fully addressed in a subsequent PR that moves the project card validation to the project card "project" ...but I'll add a quick bridge fix (was trying to not spend too much time on it b/c it will be fixed in #325 |
Resolves issues with Scenario class as discussed in #277 including:
Updated Definitions
Scenario.project_cards
: Mapping[ProjectCard.name,ProjectCard] Storage of all project cards by name; helps prevent naming conflicts.Scenario._planned_projects
: Collection[ProjectCard.name] Initial ordering of project cards which are awaiting to be queued for adding. Similar to a git working directory, project cards aren't recognized in this collection once they are moved tostaging
Scenario._queued_projects
: Collection[ProjectCard.name] Projects which are "shovel ready": have had pre-requistes checked and done any required re-ordering. Similar to a git staging, project cards aren't recognized in this collection once they are moved toapplied
Scenario.queued_projects
: @Property wrapper on _queued_projects which lazily queues (checks requirements/conflicts and orders) anything already inScenario._queued_projects
and anything inScenario.planned_projects
(and removes queued projects from planned_projects)Scenario.applied_projects
: Collection[ProjectCard.name] Projects which have been applied to the network.requisites_checked
andconflicts_checked
: as this is the definitional difference between planned and queuedScenario.projects
: Sum of applied, queued.